I'm launching them. A maintainer needs to approve them for for new contributors to run.

Got it, I thought that it just took some extra time to start and removed my question 🤦

"Segmentation fault " - that interesting. I will try to reproduce locally a bit later.

I decided not to fully reproduce this CI’s approach, since it seems to work only on Ubuntu — and I would need an emulator-in-emulator setup (Android on Ubuntu), which AFAIK my M1 can’t handle.
I used another SDK and the native toolchain for macOS (the OSS one), and I was still able to reproduce the issue. I don’t have a solution yet, but the problem is reproducible on that emulator at least (system-images;android-30;aosp_atd;arm64-v8a), even though I built the tests with 6.1.1.
If I find a solution, I’ll reply here later.

Looks like same bug, as for linux - #1071 . Which make sense... Pushing fixes.

@nathanfallet I'm not familiar with setup of test for iOS - but my changes can't break it.
May be you can point to a right direction?
Error message:

xcodebuild: error: Unable to find a device matching the provided destination specifier:
		{ platform:iOS Simulator, OS:18.0, name:iPhone 16 }

@NikolayJuly Try opening Xcode to launch manually an iPhone 16 on iOS 18.0 simulator, so it's created once and then it will find it. If you updated your Mac to a more recent version, you might have to manually download it from the "Windows & Simulator" menu.

@nathanfallet I think you might misundertood the problem. Error from CI, not from my local. CI doesn't have this simulator.
This is error message from CI.

xcodebuild: error: Unable to find a device matching the provided destination specifier:
		{ platform:iOS Simulator, OS:18.0, name:iPhone 16 }

	The requested device could not be found because no available devices matched the request.

	Available destinations for the "SQLite iOS" scheme:
		{ platform:macOS, arch:arm64, variant:Mac Catalyst, id:0000FE00-C648B17BC1592925, name:My Mac }
		{ platform:macOS, arch:x86_64, variant:Mac Catalyst, id:0000FE00-C648B17BC1592925, name:My Mac }
		{ platform:macOS, variant:Mac Catalyst, name:Any Mac }

I can spend extra time on it ofc, but it will requre me to dig through current CI setup... I would prefer to avoid it.

Looks like iOS CI start failing here - #1326
But I think, it has nothing to do with that PR, honestly. It just looks like some step misconfigured on CI.
If you don't have time, I can take a look later, especially, since I would like later to remove @convention(block) + Platform check later and working CI would help.

Looks like iOS CI start failing here - #1326 But I think, it has nothing to do with that PR, honestly. It just looks like some step misconfigured on CI.

The iOS CI failure is due to actions/runner-images#12758 (comment)

I get it. So we should update the iOS tests to use the latest available iOS instead of a fixed version maybe?

I get it. So we should update the iOS tests to use the latest available iOS instead of a fixed version maybe?

As I understand it, the options are to:

1. Override the version of Xcode in use (e.g., to 16.4 or 26)
2. Downgrade the runner to macos-14 (which didn't suffer this degradation), or
3. Wait until August 25th when the default Xcode installed on the macos-15 instances will be bumped from 16.0 to 16.4 ([macOS] Default Xcode on macOS 15 Sequoia will be set to Xcode 16.4 on August, 25 actions/runner-images#12751).

Option 3 looks okay for me, especially since I'm now trying to push my package to production on Android. I might have more info/ideas in 5 days.
But honestly, it is disappointing to see that GitHub forces such compromises and doesn’t work out of the box.

@marcprux thank you for digging up this info!

But honestly, it is disappointing to see that GitHub forces such compromises and doesn’t work out of the box.

I surmise from the 100+ comments on that thread — before they had to lock it — that they didn't quite think through the consequences of the change. It basically broke every iOS CI that uses the default configuration on macOS-15 runners.

In their defense, they usually give a bit more warning about breaking changes like these.

@nathanfallet If I understood situation correctly - if you run iOS CI again, it will pull updated image with xcode 16.4 and sim installed there. Can you try to run it, please?

@NikolayJuly I did but it was still failing. I updated the device name to match what was mentioned in the available devices in the error and maybe this time it will work.

EDIT: Does not work either. I get the same error but the other way:

xcodebuild: error: Unable to find a device matching the provided destination specifier:
		{ platform:iOS Simulator, OS:18.0, name:Any iOS Simulator Device }

	The requested device could not be found because no available devices matched the request.

	Available destinations for the "SQLite iOS" scheme:
		{ platform:iOS Simulator, arch:arm64, id:75860960-263C-416D-B8B8-60C5169ACF52, OS:18.4, name:iPhone 16 }

While before it was: (that's why I changed the name at the first place)

xcodebuild: error: Unable to find a device matching the provided destination specifier:
		{ platform:iOS Simulator, OS:18.0, name:iPhone 16 }

	The requested device could not be found because no available devices matched the request.

	Available destinations for the "SQLite iOS" scheme:
		{ platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device }

@nathanfallet I've seen initial failure, I also notice that device list first time didn't contain any actual sim. And on second run there was big list of simulators.... But looks like latest changes actually trigger test run on sim.

May be worth consider later for separate PR smth like take list from $ xcrun simctl list runtimes and just parse latest iOS sim... Cos idea of harcoding iOS version and device - looks strange for me.

@NikolayJuly yes it looks like it works with the latest one.

We might have to either keep updating it manually or have it removed/automatically select it so we don't have it broken.

At least I'll merge this one if it works because the initial goal was to fix android build. But if you feel brave enough to try this we can open a new PR for it just after merging this one.